Problem/Motivation

only having two status Blocked and Active is confusing and extremely limiting.
Why is a user Active when they have not verified their email?

Steps to reproduce

known

Proposed resolution

Add more user status and make customizable.
Unverified: user has not verified email; Inactive: user has not logged in, but is verified; Active: email verified and user logged in at least once;
Suspended: a temporary number of days being blocked from access. Banned: mod or admin permanently blocked user. Blocked: an automated system blocked user.

Remaining tasks

not sure

User interface changes

change interface to include the suggestions above.

API changes

not sure

Data model changes

not sure

Release notes snippet

Comments

dsp1 created an issue. See original summary.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

aaronmchale’s picture

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

dww’s picture

I regularly find myself having to add more granular "status" fields to users on various projects, it'd be nice if there was a clean way to do this in core.

For my most recent project, I'm using a state_machine field on user entities. It's already installed as a dependency of commerce, and so far it seems to be allowing the flexibility and power I need. If I run into any troubles with this approach, I'll probably contribute them as fixes upstream, so I imagine this can be a fairly viable recommendation for contrib until we figure out if/how/where to add this functionality to core.

It seemed like trying to use core's content_moderation on user entities was asking for trouble. 😅 But users are just content, so why not? 😂 Curious if anyone's gone down that path.

Thanks,
-Derek

kclarkson’s picture

In all the years of using Drupal I had always thought there was module to add more options for user status.

We have a use case where we want users to be archived, where we do not want them to have access to edit their account but we still want to be able to show their profile and the content they created.

It also makes a lot of sense in situations where we need accounts to be confirmed by email.

prashant.c’s picture

Yes, I think we need more granular states.

But at the same time, the statuses 'Active' and 'Blocked' as the main account statuses are good for simplicity. If we need more specific classifications, we could consider separating it with a new field say 'Account State.' This field could include statuses like 'Verified,' 'Unverified,' and 'Banned.'

IMO this approach keeps the primary account statuses straightforward and easy to manage, while also giving the flexibility to handle more detailed user states.

Thank you :)

dww’s picture

Re: #10 - indeed, that's definitely how it works with a state_machine field. If we use content_moderation, same story: the “Published” flag is still there as a single bit, but the “moderation state” is a separate, more granular field with (potentially lots) more options. While configuring states, one of the most significant options (in all such cases) is / would be: “Is this state published/active or unpublished/blocked?” (Not literally that text in the UI, but the spirit of it).

Since this issue is back at the top of my tracker, I’ll report that the project using state_machine on user entities I was talking about in #8 has launched and this aspect has been working flawlessly. So I highly endorse that for folks looking for an immediate solution to this in contrib…

prashant.c’s picture

@dww

Yes definitely, the state_machine module you suggested is extremely good and it looks like it is being actively maintained as well from the very beginning.

Thanks!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.